As the number of computers that needed or wanted to be connected to the Internet continued to grow, it soon became obvious that this number could not be accommodated by the number of available IP addresses, known as dotted-quads. In response to this address depletion problem, a method as illustrated in FIG. 2 was devised whereby a number of computers C1, C2 etc. could be located on a “private” network 60 and would use private IP addresses 62 to communicate with each other. These private IP addresses could be reused on other private networks since no one outside the private network could see these addresses. In order to allow the computers on the private network to communicate with other computers S1, S2, etc. on a public network, such as the Internet 64, the private network utilizes one machine 66 to provide the gateway for all of the computers on the private network to reach the public network. Through the use of the private addresses 62 on the private network 60 and the gateway computer 66, the address depletion problem is at least slowed.
This gateway computer 66 runs a program called a network address translator (NAT) that has both a private IP address 62 and a public IP address 68. As computers on the private network attempt to establish sessions with a server on a public network (or another private network), the NAT changes the source address 70 of the message packets 72 from the private address of the client computer to its public IP address. In this way, the private IP address is not communicated on the public network. The messages all appear to have come from the public IP address of the NAT machine. The NAT maintains a mapping 74 of the translation from the private to the public IP address so that when messages are received from the public network in response as illustrated by line 76, the NAT can forward them to the proper client machine. This operation of the NAT is completely transparent to the client computers on the private network, i.e. they each believe that they are communicating directly with the public servers.
FIG. 3 illustrates this redirect capability of the NAT machine. Specifically, a client machine C1 attempts to establish a session 78 directly with public server S1 as indicated by dashed line 80. However, when the message from C1 is detected by the NAT 66, it dynamically redirects 82 the message to S1 and changes the source address as described above. The client process does not know that the NAT has changed its messages' source address, and continues to believe that it is communicating directly with the public server. Messages from the server S1 are dynamically redirected 82 to the client C1 based on the mapping of the address translation. As may be seen from FIG. 4, this address translation takes place at a low level, e.g. at the kernel level 84 in a Window's architecture.
While the NAT has greatly alleviated the address depletion problem, especially for home and small business networks, its translation of source addresses is fixed within its programming. That is, the traditional NAT does not allow any application control of the address translations that it performs. Additionally, since the address translation is performed on the message packets at such a low level within the kernel 84, the NAT can add almost no value, other than providing the raw source address translation. The NAT cannot even provide any destination address translations. If added value is desired, such as centralized virus scanning, site blocking, white listing, etc., a proxy must be used instead.
Traditional proxies, as illustrated in FIG. 5, are application programs existing in the user mode 86 that serve as the interface between the private 60 and the public 64 network (see FIG. 6). Unlike NATs, the proxy 88 must be addressed directly by the client machines as seen in the destination address field 90 of message packet 92, and therefore requires that the client applications C1, C2, etc. be setup to operate with a proxy 88. Many applications cannot do this, or require specific configuration changes to allow the use of a proxy, and therefore a proxy configuration may not be appropriate for all applications. When a proxy application 98 is used, all communications are sent to the proxy in the user mode 86 (see FIG. 5) as illustrated by lines 94, 96. The proxy 98 then determines whether and to whom to forward the communication on the public network. If the proxy determines that the message may be passed to a server on the public network, the proxy establishes a second session 100, copies the data to the second session, changes the source and destination address, and sends out the message (see, also FIG. 7). In operational terms as illustrated in FIG. 7, a client process C1 establishes a first session 94 with the proxy 88 requesting access to a public server S1. If the proxy agrees, a second session 100 is established with the server S1 on the public network 64. Since all messages must pass from the kernel-mode network transport, e.g. TCP/IP 102, to the user-mode proxy 98, be copied to a second session, transferred back down to the kernel-mode driver 102, and finally transmitted to the network for the network application's other session, a significant performance degradation occurs.